Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

本篇是 建構安全軟體開發 系列文的 EP28。

Secure Design Patterns

在 SEI 於 2009 年出版的 Secure Design Patterns 論文摘要提及：

The cost of fixing system vulnerabilities and the risk associated with vulnerabilities after system
deployment are high for both developers and end users.
... 略 ...
The patterns were derived by generalizing existing best security design practices and by extending existing design patterns with security-specific functionality. They are categorized according to their level of abstraction: architecture, design, or implementation.

所以簡單的結論有關 Secure Design Patterns 可分成以下三個層級：

• Architectural-Level Patterns (架構層級)
• Design-Level Patterns (設計層級)
• Implementation-Level Pattern (實作層級)

Architectural-Level Patterns

要在必須文件中明確定義 Architectural-Level 的各種 Patterns 設計，有關系統間不同層級之間的程式存取互動時，其職責與權限劃分要有架構性規劃，可根據下列幾個模式考慮：

• Distrustful Decomposition：系統中不同層級的程式要存取時保持不信任的權限分隔措施。
• PrivSep (Privilege Separation)：是建立在 Distrustful Decomposition 概念之上的進階版設計，針對需要特殊(高階)權限才能執行的程式，盡量降低其程式的執行範圍與功能。
• Defer to Kernel：在程式(A)跟程式(B)之間產生請求互動行為時，透過程式(B)向系統所提供的授權機制來進行確認，驗證其授權若由系統檢驗通過後，由程式(B)來執行處理，再回應結果給程式(A)，以避免程式(A)有不必要的權限提升的機會，例如：
  • 在 Windows API 中的針對 Authorization 觀點所定義的 Securable Objects 設計。
  • 在 Unix 中的針對 socket client-server command-line tools 的設計。

Design-Level Patterns

要在必須文件中明確定義 Design-Level 的各種 Patterns 設計，軟體元件之間盡量透過安全的設計概念來區隔劃分，可根據下列的 Object Oriented 幾個有提到的 Design Ptterns (設計範式)，將設計其系統元件組合或設計其安全設計模式的開發：

• Secure Factory (安全工廠模式)
• Secure Strategy Factory (安全策略模式)
• Secure Builder Factory (安全創造者模式)
• Secure Chain of Responsibility (安全責任鍊模式)
• Secure State Machine (安全狀態機模式)
• Secure Visitor (安全訪問者模式)

PS 這邊若是透過 Object-Oriented 觀點來撰寫 Design Ptterns 這個詞的翻譯是採用 "設計範式"，這是對 侯捷老師 的敬重用法，而其他時候提及 Patterns 時則會採用 "模式"。

這裡以設計 "安全責任鍊模式" 為例：
如果考慮實作一個報表產生系統，那各種不同身份(角色)的系統使用者，應該只能根據該角色的權限取得應有的報表資料，以減緩機敏資料外洩的可能性。

假設一個報表系統內部定義的角色有：
管理者、銷售分析管理者、銷售分析員、銷售實習生(角色的權限排序由高至低)。

那相關的設計概念圖應該如下：

上圖取自 Secure Design Patterns 第 49 頁 Figure 10

平常 Design Patterns 當中的 "責任鍊模式" UML 圖應該如下：

那在 "安全責任鍊模式" 所設計觀點其 UML 圖會變為如下：

上圖取自 Secure Design Patterns 第 50 頁 Figure 11

朋友們能夠自行對照一下其中有何差異。

Implementation-Level Patterns

開發實作層級的模式基本原則有以下：

• Secure Logger Pattern
• Secure Directory Pattern
• Exception Manager Pattern
• Pathname Canonicalization Pattern
• Input Validator Pattern
• Protection Proxy Pattern
• Clear Sensitive Information Pattern 第 82 頁。
• Resource Acquisition Is Initialization(RAII) Pattern 第 102 頁。

...等。

以上模式若可參考並運用在開發實作中，固然是很好，但其基本精神大致上就是在開發實作時，盡量落實 SEI 所提出的 "Top 10 Secure Coding Practice" 來去在開發實作中實踐，就可以達到很好的安全效果的！

Verification of Design

根據設計進行再次的驗證與確認。

• 針對使用到的演算法進行邏輯上的分析。
• 針對資料的應用與使用是否有正確的處理。
• 對於元件與元件之間的叫用是否合理。
• 針對硬體與軟體環境應有運作的限制是否有正確的被限制。

檢驗其實作是否符合設計，可進行以下活動：

• 進行必要的 Code Review，可再細分正規與非正規的進行，當然正規的 Code Review 頻率與需要可視其團隊的開發進度而定；非正規的部分則頻率會高於正規的 Code Review，而進行時可透過 pseudo-code 或手寫解釋文件運作。
• 對於其 Code Review 的結果進行審視。

另外，在 NIST 其中有個計劃稱之為 Software Assurance Metrics And Tool Evaluation (SAMATE) 其中有個 "The Bug Framework: BF" 的團隊。

BF 對 SEI 發表的有關 C 語言的 Secure Coding Standard 規範，而並由 BF 對其引導有關的 CWE：
https://samate.nist.gov/BF/Enlightenment/CERT%20C.html

而衍伸有興趣了解其他程式語言的 Coding Standard 可到下面的 SEI 網站查詢(但沒有 C#，顆顆)：
https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards

Microsoft 對於 "Secure Coding Guidelines" 有在微軟文件專門篇章討論 "安全程式開發的指引" 請見下方連結：
https://learn.microsoft.com/dotnet/standard/security/secure-coding-guidelines